Use Traceroute And Mtr Examples To Demonstrate How The United States Determines The Reliability Of Cn2 Lines

1. introduction: why should we test the reliability of cn2 lines from the us side?

(1) background: cn2 is an optimized backbone network for china telecom. it is often used for high-quality backhaul links from international to china and has a great impact on overseas service quality.
(2) objective: service providers, cdn or vps operators exporting from the united states to china need to evaluate the delay, jitter and packet loss of cn2 links to ensure user experience.
(3) tools: traceroute and mtr are common tools for determining paths and real-time packet loss/delay, and are suitable for troubleshooting routing problems and link quality.
(4) correlation technology: the detection results directly affect server deployment, cdn scheduling, ddos protection strategies and bandwidth redundancy decisions.
(5) output expectations: provide quantifiable reliability evaluation indicators and tuning suggestions to facilitate operation, maintenance and product decision-making.

2. test environment and server configuration examples

(1) example of us detection terminal: vps (digitalocean nyc) ip 203.0.113.10, linux ubuntu 22.04, traceroute v2.1.0, mtr v0.94.
(2) chinese target example: cn2 computer room host ip 45.120.50.20, the computer room belongs to as4134 (chinanet), web service nginx 1.18, port 443.
(3) test link configuration: icmp/udp detection, ttl from 1 to 30, mtr running time 300 seconds, message size 64 bytes.
(4) network measurement frequency: traceroute + mtr every hour (lasts for 5 minutes), and reports the results to the monitoring platform (prometheus + grafana).
(5) security precautions: during detection, avoid production peaks and comply with the detection strategy of the target network. if necessary, communicate with the other party's operation and maintenance to avoid false positives as ddos.

3. traceroute sample output and table display

(1) command example: traceroute -i -m 30 45.120.50.20 (use icmp to pass through the isp firewall policy).
(2) note: the ip and delay of each hop can be used to identify the jump point entering cn2 and whether there is an obvious jump or cross-domain hop.
(3) sample data table (some hops):

hop	ip	asn	rtt(ms)
1	203.0.113.1	as6389	0.8
6	198.51.100.45	as3356	28.5
9	87.248.112.10	as174	85.2
12	202.97.33.1	as4134	210.6
14	45.120.50.20	as4134	215.1

(4) interpretation: a sudden increase in rtt (85 -> 210 ms) occurs between jumps 9 to 12, which usually indicates entering the transoceanic or being forwarded to the cn2 edge.
(5) conclusion: if traceroute loses packets or rtt increases sharply after entering as4134, it indicates that there may be congestion or priority policy issues at the cn2 edge or backhaul segment.

4. mtr examples and statistical analysis

(1) command example: mtr -rwzbc 100 45.120.50.20 (run 100 packets to display packet loss and delay).
(2) example key output (summary): last hop loss% 2.0%, best 210ms / avg 217ms / worst 240ms / stdev 5.1ms.
(3) key points of hop-by-hop analysis: if the loss% of an intermediate hop is high and the loss% of subsequent hops is low, it means that the intermediate router has a speed limit for icmp but does not affect the actual traffic.
(4) example judgment: if last-hop packet loss >1% or avg rtt >220ms, and jitter (stddev) >10ms within 5 consecutive minutes, the experience is considered to be significantly degraded.
(5) operation suggestions: for hops with persistent packet loss or high latency, submit a work order to the upstream isp and provide the mtr/traceroute timestamp and pcap for easy location.

5. quantitative indicators and thresholds to determine the reliability of cn2 lines

(1) indicator 1: packet loss (packet loss), threshold recommendation: long-term last hop ≤1% is acceptable, 1-3% is a warning, and >3% requires investigation.
(2) indicator 2: average latency (avg rtt), threshold recommendation: <=200ms is good, 200-250ms is close to the threshold, and >250ms affects the interactive experience.
(3) indicator 3: jitter (jitter/stddev), threshold recommendation: <=10ms is good, 10-25ms needs optimization, >25ms significantly affects tcp/real-time services.
(4) indicator 4: routing stability (frequency of bgp path changes). if there are >3 path switches within 24 hours, you need to pay attention.
(5) indicator 5: bandwidth and packet loss consistency. use the iperf3 test to confirm whether the throughput is consistent with the icmp indicator to determine whether it is a control plane speed limiter.

6. real case analysis and optimization suggestions (including server configuration examples)

(1) real case: a us cdn node to the cn2 target experienced 4% packet loss during working hours. the mtr pointed to the cn2 edge router (as4134) was a high packet loss point. after communicating with the domestic computer room, it was confirmed that it was edge peak congestion.
(2) processing process: provide traceroute (including timestamp) and mtr reports to the domestic communication party. the as peer schedules the traffic project within 6 hours, and the packet loss is reduced to 0.5%.
(3) server configuration example: source station nginx optimization - worker_processes auto, keepalive_timeout 65s, tcp_nodelay on, sysctl adjustment: net.ipv4.tcp_tw_reuse=1, net.core.rmem_max=33554432.
(4) redundancy and strategy: deploy dual exits (directly connected to cn2 and ordinary international links), and use gslb or cdn health detection strategies to switch back based on packet loss/delay.
(5) ddos and line protection: enable upstream cleaning, rate limiting and syn cookies for periods of sudden jitter or large-scale packet loss; and add threshold alarms (packet loss > 1.5% or avg rtt > 230ms) to monitoring.